home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group95c.txt
/
000106_icon-group-sender _Fri Dec 1 09:54:05 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1996-01-03
|
2KB
Received: by cheltenham.cs.arizona.edu; Fri, 1 Dec 1995 07:19:36 MST
Date: Fri, 1 Dec 1995 09:54:05 +0200 (WET)
From: Ehud Lamm <mslamm@pluto.mscc.huji.ac.il>
To: gep2@computek.net
Cc: icon-group@cs.arizona.edu
Subject: Re: "Simplification" of Icon
In-Reply-To: <9511301400.AA21916@ns1.computek.net>
Message-Id: <Pine.A32.3.91.951201094455.37593C-100000@pluto.mscc.huji.ac.il>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: icon-group-errors@cs.arizona.edu
On Thu, 30 Nov 1995 gep2@computek.net wrote:
> >I'd personally love to see a language like Icon that did away with auto-
> matic type conversions (I rarely used them anyway),
>
> Are You Kidding!!!??? That is one of the things that is the MOST BASIC about
> the appeal of something like ICON (or SNOBOL4, for that matter)... that if
> something is numeric, you can treat it like a number... without having to do
> manual conversions on it! And that likewise, you can treat numbers like strings
> when it's appropriate and desirable to do so!
I think the Icon group survived quite well without flaming. I think we
can continue with this tradition. Ad-hominem remarks are really
disgusting (don't YOU think) :-)
Anyway the issue raised is an important one.
Automatic conversion can be terrible (see PL/1 for an example), when they
don't work as expected - and I have seen many such cases in other
languages.
On the other hand hidden type information and conversions are also basic
tools used in many VHLL (very high level languages) such as Rexx, SNOBOL,
Icon etc.
The problem is to find the right combination of ease of use ("123"+4) and
type safety ("0.1" + 1 is an integer, a float or maybe it doesn't matter
which??).
I think Icon is pretty good in this respect, though I must add I didn't
really try to break its type system recently.
We have to remember the VHLL raise many issues not found in normal HLL
design. A VHLL must allow you to rapidlly code and debug, without having
to deal with to many technical obstacles. This also means that it is not
always such a great idea to say "you can just link to C" since this adds
to the work of the programmer.
On the other hand VHLLs like all languages should be orthogonal and clean
- and not suffer from to many diconected features. But again, I think
this hardly characterizes Icon.
Ehud Lamm mslamm@pluto.mscc.huji.ac.il